In its infancy, the Internet was a communications system funded and built by researchers for military use. This Internet, originally known as ARPANET, was embraced by the research and academic world as a mechanism for scientists to share and collaborate with other scientists. This collaborative network quickly evolved into the information superhighway of commerce and communication. The Internet explosion was due, in part, to the development of the World Wide Web (WWW) and Web browsers, which facilitated a more graphically-oriented, multimedia system that uses the infrastructure of the Internet to provide information in a graphical, visual, and interactive manner that appeals to a wider audience of consumers seeking instant gratification.
Referring to the Internet as the information superhighway is a metaphor for the mechanism of transporting data from one location to another. As technology has increased, allowing higher and higher bandwidth rates, streaming larger data files, such as audio and video, has become increasingly more available. Streaming larger data files is generally an extension of simply displaying a large data file in a local system. One of the main differences, and a problem with remote streaming applications, is the bandwidth requirements. In a local system, because the data is typically located on a local disk drive or storage system, the access and processing time is minimal. As the client of the file moves further away from the storage location, the longer it will take to view the material. For example, in a local area network (LAN) setting, the data file is still essentially local, but will take a little more time to access and process than in a purely local set up because of the bandwidth attributes and limitations of the LAN. Furthermore, in a wide area network (WAN) or the Internet, because the accessing client is typically located in a remote location from which the bandwidth has some defined limitation, the accessing and processing of the remote data will take much more time than even the LAN application.
Streaming video content over a WAN or the Internet is typically conducted using a particular video format that is then played on a compatible media player running on the client. The video file may generally reside at a centralized location or server. The client system will transmit a request to the server to view the video file, which will cause the server to begin downloading the video file to the client system. When enough of the file has been downloaded, the compatible player will begin displaying the video to the user. Examples of such video formats are MACROMEDIA INC.'s FLASH™ VIDEO (FLV), APPLE COMPUTER CORPORATION's QUICKTIME™ VIDEO, MICROSOFT CORPORATION's WINDOWS™ MEDIA VIDEO (WMV), REALNETWORKS INC.'s REALVIDEO™, and the like.
The video files may be completed files stored in a centralized location or may be reflecting live video captured from a camera and converted into the particular video format before transmission. In viewing video files, it may be desirable for a user to seek to a particular point in the video. Many media players include a progress bar that graphically indicates the running progress of the playing video. Some such players also include slider controls that allow the viewer to change the viewing position of the playing video. This type of control is often referred to as random seeking (i.e., random in the sense that a user is allowed to move the video to any position that he or she desires). When the user moves the slider to the desired position, the media player signals the central server to advance the media stream to the beginning of the frame closest to that seek point.
In the days before electronic video, video was generally played from some sort of tape. The tape was spooled onto a roll and unrolled over one or more reading heads to capture the video and audio data from the tape. In such historic, non-electronic systems, in order to move forward or backward in the video, the tape is linearly fast-forwarded or rewound in order to reach the specific location. Depending on the size or length of the tape, the speed of the machine, and other similar characteristics, the rewind or fast-forward would potentially take a considerable amount of time. However, electronic data is not physically limited to a sequential, linear progression in the same manner that tape is. Therefore, some electronic data files may be accessed in a non-linear fashion.
In general application, there are indexed media files and non-indexed media files. Indexed files include a detailed index, which may be part of the same file or an associated file, that provides information about the content of the media content. Using such an index in a media file may allow the compatible media player to access the desired location without systematically scanning thru the actual media file. Because there is an index, the player would generally look up the location on the index and then jump to that location in the media content. However, such an indexing system requires a great deal of overhead and maintenance to keep current.
An index keeps track of the file contents. If anything in the file changes, the index will be changed also to reflect the change in the media file. Therefore, if a video designer changes or adds any content to the file, the index will be updated. Furthermore, when accessing such an indexed file, a determination would be made whether the index file is stale or too old to be reliable. When the user moves the slider to the desired location, the server would typically perform a linear search of the index and then jump to the specified location in the media file to transmit or download to the requesting client. The time-cost in performing the linear search of the index and jumping to the specified location in the file provides a degree of improvement over a straight linear search of the media content. However, the linear search of an index is still a slow search.
The time cost of generating the index is also fairly high to the cost of generating the index in the first place. Many indexing utilities will automatically generate the index by linearly sequencing through the media content. This linear sequencing typically takes as much time as sequencing through the media content to play it. When the media content is changed, some indexing utilities do not merely change the index, but instead completely regenerate a new index. Thus, in some applications, each time a change is made, considerable time is spent fully generating a new index.
Non-indexed files are intended to have little overhead and maintenance requirements to allow greater flexibility in the creation and editing of the video file. Non-indexed media files basically consist of a stream of frames that make up the media information. Each frame is simply sequential to the previous. This simple structure allows for free splicing and editing of the media file without creating a need to re-order an index, a table of contents, or the like. In general, a non-indexed media file will have each of its frames begin with a header section that identifies the beginning of the frame, the frame length, the codec used, a time stamp, and the like. The order that this administrative information is placed into the frame header depends on the rules of the particular media format that is used. One format may place the frame length in the byte following the frame beginning indicator, while another format places the frame length in the fifth byte of the header. The specific order of such header information is generally not standard across all media formats. Moreover, some formats, such as FLV, add additional macro-header information that includes items such as a back tag pointer. A back tag pointer is a byte or bytes located at the end of the frame that points to the beginning of that frame. This macro-header information envelopes the frame payload. All of this administrative information allows the transmitting server and the receiving player to decipher, control, and, for the receiving player, play the intended media stream, but is not so extensive that a developer would not be able to freely edit the frames in the media file.
To seek through a non-indexed media file, the server typically performs a linear scan of each frame of the file in sequence to arrive at the desired frame. This linear scan does not generally take as long as simply playing the file in real-time, but may only save a constant order of time. Thus, a video file that has millions of frames, or that lasts for an hour or more, may take 15, 20, or even 30 minutes or more just to seek to the middle or later part of the video file. In terms of viewing video over the Internet, this delay would be unacceptable to most users.
One method that has been used to improve the performance in seeking through non-indexed media files is to actually generate an index or table of contents on the storing server. By generating such an index or table of contents, the seek-time performance may be improved slightly over that of a regular non-indexed file. However, again, the overhead of creating and maintaining the index makes this minor improvement less appealing. Moreover, adding an index to a non-indexed media file defeats the purpose and benefits of having no index.